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Unv randeHiches Exemplar \ . *!* y 

ExempJaire invariable ^ _ *" 

dsempJare' limmti'iabille 

^ METHODE DE SECURISATION DES RAISES A JOUR DE LOGICIELS 

La presente invention conceme une methode de securisation des mises a jour de 
logiciels d'exploitation assurant le fonctionnement de systemes les plus divers. Plus 
particulierement, la methode de invention utilise un mecanisme de signature 
5 numerique avec une cle privee d'un algorithme d'encryptage asymetrique. 

Un systeme est defini ici comme un appareil ou un ensemble d'appareils dont le 
fonctionnement depend d'un ou plusieurs logiciels stockes dans une memoire non 
volatile ou un disque dur. Lorsque les fonctionnalites du systeme doivent etre 
ameliorees ou completees afin de s'adapter aux exigences croissantes de 
10 Tutilisateur, il est souvent necessaire de mettre a jour uniquement le logiciel 
concerne sans pour autant changer le materiel constituant le systeme. 

La mise a jour d'un logiciel donne s'effectue en general par remplacement de fichiers 
d'un logiciel deja installe ou par ajout de nouveaux fichiers venant completer ceux 
qui sont stockes. L'ensemble constitue alors une nouvelle version du logiciel 
15 prealablement installe dans le systeme qui beneficie ainsi des ameliorations 
souhaitees. 

De nombreux appareils tels que des ordinateurs et leurs peripheriques, des 
automates de vente, des telephones fixes et portables, des decodeurs de television 
a peage, etc. sont pilotes par des logiciels adaptes a leur configuration et aux 
20 fonctions de composants specifiques. 

Par exemple, dans un decodeur de television a peage (Set Top Box), un logiciel 
d'exploitation gere des peripheriques tels qu'un disque dur, un lecteur de cartes a 
puce, des interfaces de reception de donnees et des memoires. Afin d'introduire des 
changements soit au niveau de la configuration, soit au niveau des fonctionnalites, il 
25 est parfois necessaire de remplacer le logiciel existant ou d'apporter des 
ameliorations a celui deja installe dans le decodeur. Ce type devolution s'effectue au 
moyen de portions de logiciels que Ton appelle mises a jour ou patchs fournis par le 
centre de gestion de I'operateur auquel un certain nombre d'utilisateurs sont 
abonnes. Ces mises a jour sont fournies regulierement par le centre de gestion et 
30 telechargees dans les decodeurs de chaque abonne possedant les droits 
necessaires. 



Les utilisateurs cPun decodeur possedent en general un contrat payant chez un 
operateur qui leur garantit un service de maintenance regulier du logiciel installe 
dans le decodeur. Afin de limiter les abus par copies non autorisees et par 
introduction de composants logiciels etrangers, il devient indispensable de securiser 
5 les mises a jour du logiciel du decodeur. Une methode connue consiste a utiliser une 
empreinte codee avec une cle d'un algorithme d'encryptage asymetrique du type 
RSA. Le logiciel de mise a jour est fourni en ligne avec une empreinte obtenue par 
une fonction de hachage a sens unique (Hash). Cette empreinte constitue une image 
unique representant I'ensemble de la mise a jour et il est admis qu'il n'existe pas 

10 deux empreintes identiques sur deux meme ensembles de donnees differents. Cette 
empreinte est encryptee a I'aide d'une cle privee de I'operateur associee a un 
ensemble d'abonnes, ce qui constitue une signature propre a cet ensemble. Le 
logiciel accompagne de cette signature est charge dans une memoire vive RAM 
(Random Access Memory) du decodeur. Un programme faisant partie du logiciel du 

15 decodeur calcule avec la fonction de hachage (Hash) une empreinte du logiciel 
stocke dans la memoire RAM. La signature regue est decryptee avec une cle 
publique contenue dans le decodeur puis comparee avec I'empreinte du logiciel 
calculee auparavant. Si la signature decryptee correspond a I'empreinte resultante 
du hachage, la signature accompagnant la mise a jour stockee dans la memoire 

20 RAM est consideree comme valide. Le logiciel de mise a jour sera installe dans la 
memoire non volatile du decodeur (memoire Flash). 

La securisation est ainsi realisee par la verification de la signature avec une cle 
publique dans le decodeur correspondant a la cle privee de Toperateur. 

La cle publique residant dans le decodeur doit etre fixe ainsi que le programme qui 
25 permet la verification de la signature. L'authenticite de la signature est assuree du 
fait que la cle privee depend de la cle publique du decodeur. La signature ne peut 
pas etre reproduite car la cle privee n'est connue que d'un operateur determine. De 
plus, une meme signature est inutilisable pour plusieurs mises a jour differentes car 
elle est une fonction d'une mise a jour bien definie. Un logiciel de mise a jour signe et 
30 dont le contenu est modifie dans la memoire RAM donnera une autre empreinte qui 
ne peut done pas etre validee par la signature decryptee par la cle publique. En effet, 
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I'empreinte resultante apres hachage de la mise a jour au niveau du decodeur et 
differente de celle obtenue apres decryptage de la signature. 

Cependant, cette methode de securisation comporte un point faible qui est la cle 
privee de I'operateur elle-meme. En effet, lorsque celle-ci est decouverte par un tiers, 
5 il peut signer un logiciel quelconque et apporter des modifications abusives au 
systeme. 

Cette decouverte peut se faire sous forme d'iteration sur la cle publique que ce tiers 
aura extraite au decodeur, jusqu'a ce qu'il decouvre la bonne paire de cles. La 
parade consistant a modifier le comportement le logiciel du decodeur pour qu'il 
10 refuse les signatures generees avec la cle decouverte est insuffisante car le tiers 
peut contourner ces modifications avec des programmes adequats. 

Le but de la presente invention est de reduire considerablement I'impact de la 
decouverte d'une cle privee par une analyse systematique du fonctionnement du 
logiciel du decodeur ou d'accroitre notablement le temps et les moyens necessaires 
15 au processus utilise pour sa determination. 

Le but est atteint par une methode de securisation de mise a jour de donnees d'une 
pluralite d'appareils, chaque appareil recevant les mises a jour d'un centre de 
gestion, ces mises a jour comprenant des donnees appelees patch accompagnees 
d'un bloc de controle encrypte par une cle privee asymetrique prise dans une liste de 
20 cles contenue dans le centre de gestion, caracterisee par les etapes suivantes: 

- selection par Pappareil d'une cle courante dans une liste de cles publiques, 

- reception du patch de mise a jour et stockage en memoire, 

- reception du bloc de controle encrypte, 

- decryption dudit bloc par la cle publique courante, 

25 - verification que le bloc de controle decrypte corresponde audit patch, 

- installation du patch re?u, 

- deactivation de la cle courante et selection de la cle suivante dans la liste. 

Les donnees d'une mise a jour sont transmises par le centre de gestion sous forme 
d'un patch et d'un bloc de controle comprenant une signature constitute par 
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rempreinte du patch encryptee avec une cle privee du centre de gestion. Le 0' 
decodeur stocke ces donnees dans la memoire vive RAM en vue de leur traitement. 
Une cle publique, associee a cette cle privee appelee cle courante, est selectionnee 
a partir d'une liste stockee dans une premiere memoire non volatile afin de decrypter 
5 la signature du patch. En cas de succes de la decryption et de la verification, une t5 
commande est executee aboutissant a Installation du patch dans une seconde 
memoire non volatile (Flash) du decodeur. La cle courante ainsi utilisee est 
desactivee dans la liste ce qui rend la cle suivante disponible pour la prochaine mise 
a jour. 

10 Lorsque la verification de la signature et la decryption d'une mise a jour du decodeur 
est effectuee avec une cle publique de la liste, celle-ci est biffee et devient 
inutilisable pour de prochaines mises a jour. Done, a chaque mise a jour, une 
nouvelle cle est utilisee puis eliminee de la liste. Les cles publiques de la liste 
doivent etre non modifiables tout comme le programme servant a la verification des 

15 signatures. La liste n'est modifiable (elimination des cles utilisees) que par le 
programme de verification. 

La methode decrite ci-dessus permet de reduire considerablement les possibilites de 
modifications du decodeur par un tiers ayant decouvert une cle privee. Puisqu'une 
cle n'est utilisable qu'une seule fois, le tiers n'effectuera qu'une seule modification. 
20 Par consequent une modification du comportement du decodeur pour le proteger 
des effets du piratage devient plus efficace car le tiers, ne disposant plus de cle 
privee valable, se trouve ainsi devant un appareil inaccessible. 

Du fait que les cles privees utilisables sont plus nombreuses, un tiers doit done 
attaquer systematiquement toutes les cles pour qu'il ne soit pas bloque a une mise a 
25 jour qui correspond a la cle qu'il a decouverte. II faut savoir que revolution du logiciel 
des decodeurs est rapide et que Ton considere que si une des cles est decouverte, 

i 

les mises a jour suivantes vont refermer les failles de securite que le tiers aurait pu , 
introduire. Si ce tiers est capable de bloquer toute mise a jour post^rieure, les 
fonctionnalites du decodeur seront rapidement obsoletes et done sans grand 
30 prejudice pour Toperateur. 



Ig) ^utilisation de cles asymetriques est importante dans ce contexte car I'extraction des 

cles publiques dans un decodeur ne permet pas de fabriquer une mise a jour 
acceptable puisque cette mise a jour doit etre signee par la cle privee de I'operateur. 
II est commun de placer les cles privees dans la partie securisee (I'operateur) et les 

Ml 5 cles publiques dans la partie dans le domaine public (le decodeur). Neanmoins, il est 
possible d'inverser ces cles sans nuire au fonctionnement de la presente invention. 

Un premier mode de realisation de I'invention propose I'utilisation de cles publiques 
prises dans un ordre predetermine a partir de la liste. Ainsi, chaque cle de la liste est 
prise des que la cle precedente est utilisee. 

10 ^invention sera mieux comprise grace a la description detaillee qui va suivre et qui 
se refere aux figures annexees servant d'exemple nullement limitatif, a savoir: 

- La figure 1 represente le deroulement d'une etape de mise a jour d'un decodeur 
d'une version N a une version N+1 . 

- La figure 2 montre une mise a jour d'une version N vers une version R 

15 Dans I'exemple illustre par la figure 1, un decodeur de version initiale est mis a jour 
vers la version 1 avec un patch P1. Ce patch P1 est transmis avec sa signature 
(H(P1))pki par le centre de gestion de I'operateur vers le decodeur. L'etape de mise a 
jour debute par le chargement du patch P1 dans la memoire RAM du decodeur. 

La signature (H(P1)) PK i est obtenue par encryption de I'empreinte H(P1) du patch P1 
20 avec la cle privee PK1 de I'operateur, operation effectuee dans le centre de gestion. 
Cette empreinte est calculee par Toperateur a partir du patch P1 avec une fonction 
de hachage H a sens unique de type Hash. 

Le logiciel du decodeur se charge ensuite de decrypter la signature (H(P1)) PK i regue 
avec une cle publique K1 afin d'obtenir Tempreinte du patch H(P1)i. Parallelement, 

25 ce meme logiciel calcule Tempreinte H(P1) 2 du patch P1 stockee dans la memoire 
RAM. La premiere empreinte issue de la decryption de la signature H(P1)i et la 
seconde H(P1) 2 resultante du calcul par la fonction de hachage H sont comparees. 
Si les deux valeurs concordent, le patch P1 est installe dans la memoire non volatile 
Flash FH du decodeur realisant ainsi la mise a jour du logiciel du decodeur. La cle 

30 publique K1 utilisee pour decrypter la signature est biffee de la liste. 




Une seconde mise a jour de la version 1 vers la version 2 transmise par le centre de (gf 
gestion sous forme d'un nouveau patch P2 accompagne de sa signature (H(P2)) PK 2 
passe par le meme procede de telechargement et de verification. Une nouvelle cle 
publique K2 prise dans la liste sera alors utilisee du cote du decodeur. Toutes les 
5 mises a jour suivantes transmises sont verifiees de la meme maniere en utilisant 
chaque fois une nouvelle cle publique prise dans la liste. Les cles des mises a jour 
precedentes sont neutralisees soit par effacement, soit par un marquage adequat. 

En appliquant ce procede, une mise a jour d'un logiciel de la version 1 vers une 
version N s'effectue en N-1 etapes. Le centre de gestion transmettra N-1 patchs 
10 avec N-1 signatures correspondantes encryptees chacune par une cle privee propre 
a chaque version. L'installation des differents patchs entrame done la neutralisation 
de N-1 cles publiques de la liste. 

La liste des cles publiques peut etre stockee par exemple dans une memoire non 
volatile du type EEPROM (Electrically Erasable Programmable Read-Only Memory). 
15 Apres chaque utilisation d'une cle lors d'une mise a jour, celle-ci est effacee 
definitivement de I'EEPROM autorisant I'acces a la cle suivante pour la prochaine 
mise a jour. 

Selon un autre mode de realisation, la liste des cles publiques n'est pas alteree par 
un effacement ou un marquage d'une cle. Apres chaque installation d'une version de 

20 logiciel dans la memoire non volatile Flash, un compteur est increments ou un 
pointeur se deplace pour indiquer le rang de la cle a selectionner dans la liste lors de 
la prochaine mise a jour. Ainsi lors de chaque mise a jour, seule la cle qui servira a 
decrypter la signature du patch est designee, les cles precedentes ne pouvant plus 
etre selectionnees car le compteur ou le pointeur ne peut progresser que dans un 

25 seul sens, celui des rangs croissants. 

Selon une variante, le patch peut etre encrypte par la cle privee de Toperateur. Une 
etape supplemental de decryption s'ajoute done au procede decrit ci-dessus. Le 
patch P regu et charge dans la memoire RAM peut etre decrypte avec la cle publique 
avant le calcul par la fonction de hachage H de Tempreinte servant a la verification 
30 de la signature. Le calcul de Pempreinte peut egalement etre effectue sur les patchs 
sous sa forme encryptee egalement. 
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^installation de mises a jour par des tiers est rendue plus difficile car chaque 
changement de version exige la connaissance de la cle courante. Cette derniere 
change a chaque mise & jour ce qui oblige le tiers a connaTtre toutes les cles pour 
suivre les differentes mise a jour. 

5 Le procede decrit precedemment peut poser un probleme lorsque le decodeur est 
reste hors service le temps ou plusieurs mises a jour devaient etre effectuees. Le 
passage d'une ancienne version d'un logiciel a une nouvelle dont le numero n'est 
pas consecutif a celui de la precedente version s'effectue sequentiellement en 
plusieurs etapes successives. Ces dernieres utilisant des cles publiques differentes 
10 prises dans la liste Tune apres I'autre et dans I'ordre. II est rappele que le patch en 
lui-meme ne contient pas d'ordre permettant de selectionner une cle differente que la 
cle courante. Si tel etait le cas, un tiers pourrait utiliser cette commande pour forcer 
Tutilisation d'une cle qu'il lui serait connue. 

La figure 2 illustre le cas d f un passage d'un logiciel d'une version N a une version R 
15 ou la difference R-N entre la nouvelle version et la precedente excede Tunite. 
Uexemple qui suit se rapporte a un cas ou N=2 et R=5. 

Un decodeur dont le logiciel est de version 2 ne peut pas decrypter directement la 
signature (H(P)) PK 5 de la nouvelle version 5 car la cle disponible dans la liste des 
cles publiques est celle de la version immediatement superieure, a savoir la cle K3. 
20 Pour Installation de la nouvelle version 5, il doit pouvoir acceder a la cle 
correspondante a cette version, c'est a dire la cle K5. 

La solution consiste a transmettre un flux de donnees contenant le patch P pour la 
mise a jour du logiciel du decodeur a la version 5 signe avec la cle PK5 auquel 
s'ajoute une pluralite de messages M1, M2, M3, M4 encryptes chacun avec une cle 
25 privee PK1, PK2, PK3, PK4 tiree de la liste de cles. La memoire vive RAM stocke 
ces messages ainsi que le patch P avec sa signature (H(P)) PK 5. La version du 
decodeur etant 2, la cle de la mise a jour de la version 1 a 2 est deja desactivee par 
la premiere mise a jour. Le message M1 est alors ignore car la cle K1 servant a le 
decrypter n'est plus disponible. 
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Les messages suivants M2, M3 et M4 servent a desactiver Tune apres Tautre les cles 
publiques K2, K3, et K4 correspondantes a chaque version intermediaire depuis la 



version 2 jusqu'a la version 4 precedant la version 5. Ainsi pour installer la version 5 ^ 
dans la memoire non volatile Flash, chaque cle publique K2, K3, et K4 de la liste est 
utilisee puis neutralisee ou biffee. Lors de la decryption du message par la bonne 
cle, le contenu de ce message est reconnu et provoque I'operation de neutralisation 
5 de la cle courante. Si le message n'est pas reconnu, ceci signifie que la cle Q 
d'encryption de ce message n'est pas la cle courante. 

Apres la decryption successive et reussies des messages M2, M3, M4, la cle K5 
necessaire a la decryption de la signature du patch (H(P)) PK5 (et du patch P) devient 
la cle courante. Cette derniere sera aussi biffee de la liste apres Installation du 
10 patch et la cle K6 sera presente en tete de liste pour la prochaine mise a jour de la 
version 5 vers la version 6. 

Un tel flux peut done mettre a jour tout un pare de decodeurs quelle que soit leur 
version de logiciel grace aux messages de changement de cle accompagnant le 
patch. Chaque decodeur dispose d'une cle publique dans la liste capable de 
15 decrypter une mise a jour de la version courante apres neutralisation des anciennes 
cles. 

Lors d'une mise a jour du logiciel d'un decodeur d'une version N a une version R ou 
la difference R-N devient grande, par exemple superieure a 10, il devient fastidieux 
pour un decodeur qui a une version R-1 de decrypter systematiquement tous les 
20 messages afin de verifier les ordres de deactivation. Ce decodeur va appliquer sa 
cle courante (R-1) a chacun de ces messages pour constater qu'il ne peut pas 
interpreter son contenu. 

Une premiere solution consiste a introduire en clair dans I'en-tete des messages des 
index correspondant aux numeros des differentes versions. Cet index sert 
25 uniquement a eviter la decryption des messages qui ont ete encryptes par une cle 
differente de la cle courante. Cet index ne selectionne pas le rang de la cle courante, 
seul la decryption reussie d'un message avec ladite cle courante provoque Tavance 
d'un rang dans la liste de cles. 

Selon une deuxieme solution, Tempreinte du patch de mise a jour est encryptee 
30 successivement par toutes les cles privees des mises a jour precedentes. Ce 
procede oblige une utilisation de chaque cle publique de la liste, Tune apres Tautre, 



S P our d6cr YP ter la signature. Dans ce cas d'encryption en chaTne, contrairement au 

precedent, toutes les cles publiques doivent rester disponibles dans la memoire 
EEPROM du decodeur. Par exemple, pour une mise a jour de la version 1 vers la 
version N, I'empreinte du patch P est encryptee avec une cle privee de la version N. 
5 L'ensemble est ensuite encrypte avec la cle privee de la version N-1, puis avec la cle 
de la version N-2 et ainsi de suite jusqu'a la version 1 . La decryption necessite done 
Tutilisation successive des cles publiques K1 a KN-1 correspondantes aux mises a 
jour de la version 1 a la version N. L'arret de ce mecanisme iteratif se fait par la 
reconnaissance d'une marque appropriee dans le resultat de la decryption. 

10 Si Ton souhaite proteger les donnees de mise a jour, une maniere de proceder 
consiste a utiliser une cle de session SK generee aleatoirement par le centre de 
gestion par exemple. Pour des raisons operationnelles de rapidite, cette cle est de 
type symetrique. Le centre de gestion encrypte le patch avec la cle de session SK et 
compose un ensemble de donnees comprenant la cle de session SK et I'empreinte 

15 du patch de mise a jour. Cet ensemble est encrypte par la cle privee courante de 
Toperateur pour constituer le bloc de controle. 

Le patch crypte et le bloc de controle sont charges dans la memoire vive RAM du 
decodeur. Le bloc est decrypte par la cle publique courante dans la liste ce qui 
donne I'empreinte du patch et la cle de session SK. Cette derniere est appliquee au 
20 patch charge dans la memoire RAM permettant sa decryption. Puis I'empreinte du 
patch est verifiee et en cas de concordance le patch est installe dans la memoire 
non volatile Flash. 

La cle de session peut etre introduite comme moyen de securisation supplementaire 
dans Tune ou Tautre des variantes decrites plus haut par exemple: 
25 - la mise a jour simple d'une version 1 a une version N en plusieurs etapes, 

- la mise a jour d'une version N a R a Taide d'un patch et des messages de 
deactivation des cles. 

Dans un decodeur ayant ete mis a jour a de nombreuses reprises, le nombre de cles 
publiques a disposition diminue tandis que le nombre de cles desactivees augmente 
30 en meme temps que les mises a jour reussies. Afin de reconstituer une liste de cles 
pour permettre les futures mises a jour, une nouvelle liste de cles publiques peut etre 
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envoyee au decodeur par le centre de gestion. Cette liste peut etre incorporee dans 
le flux de donnees et accompagnee d'une signature comme pour un patch de mise a 
jour. Elle est stockee dans la memoire EEPROM et remplace I'ancienne liste 
contenant des cles desactivees. 

5 Selon une variante de la methode de I'invention, le centre de gestion et les 
decodeurs disposent respectivement d'une liste de cles privees et publiques fixe. A 
chaque mise a jour, le centre de gestion choisit aleatoirement un ensemble de cles 
privees parmi celles de la liste et encrypte I'empreinte du patch successivement avec 
chaque cle de I'ensemble. Le centre compose un bloc de donnees comprenant 

10 I'empreinte encryptee (signature) et une suite de numeros correspondant aux rangs 
des cles choisies auparavant. Cette suite peut etre transmise en clair ou encryptee 
avec une cle de session. Le decodeur recevant la suite de numeros selectionne 
dans la liste des cles publiques, d'apres leur rang, les cles necessaires pour 
decrypter I'empreinte du patch. La liste ne peut pas comprendre plus d'une fois le 

15 meme numero de cles et la longueur de cette liste (nombre de cles utilisees) est 
connue et non modifiable. Dans cette variante, les listes de cles restent fixes et ne 
sont pas alterees suite a une installation reussie d'un patch. A chaque mise a jour, 
une nouvelle combinaison de cles prises dans la liste est utilisee pour la signature du 
patch. Un tiers devra done toujours disposer d'un ensemble de cles pour introduire 

20 une mise a jour dans un appareil, ce qui necessite des moyens plus consequents 
que pour la determination d'une seule cle. 

Le precede de securisation de mise a jour selon I'invention est independant du mode 
de transmission utilise entre un fournisseur et un utilisateur. En effet, le precede peut 
aussi s'appliquer sur des patchs distribues sur CD-ROM, sur disquette ou sur tout 
25 autre support de donnees numeriques. 



REVENDICATIONS 



1. Methode de securisation de mise a jour de donnees d'une pluralite 
d'appareils, chaque appareil recevant les mises a jour d'un centre de gestion, ces 
mises a jour comprenant des donnees appelees patch accompagnees d'un bloc de 
controle encrypte par une cle privee asymetrique prise dans une liste de cles 
contenue dans le centre de gestion, caracterisee par les etapes suivantes: 

- selection par I'appareil d'une cle courante dans une liste de cles publiques, 

- reception du patch de mise a jour et stockage en memoire, 

- reception du bloc de controle encrypte, 

- decryption dudit bloc par la cle publique courante, 

- verification que le bloc de controle decrypte corresponde audit patch, 

- installation du patch regu, 

- deactivation de la cle courante et selection de la cle suivante dans la liste. 

2. Methode selon la revendication 1 caracterisee en ce que le bloc de controle 
comprend une signature sur les donnees du patch, cette signature etant le resultat 
d'une fonction de hachage, et en ce que la verification du bloc comprend I'etape 
d'etablissement de la signature sur le patch regu et la comparaison avec la signature 
decryptee dans le bloc de controle. 

3. Methode selon la revendication 1 ou 2, caracterisee en ce que le bloc de 
controle comprend une cle de session symetrique (SK) determinee par le centre de 
gestion, cette cle etant utilisee pour encrypter les donnees du patch. 

4. Methode selon la revendication 1 ou 2, caracterisee en ce qu'a chaque mise a 
jour une nouvelle cle publique, issue de la liste, est utilisee par I'appareil. 

5. Methode selon les revendications 1 a 4, caracterisee en ce que la cle 
publique est detruite de la liste apres son utilisation, ladite cle devenant inutilisable 
pour des mises a jour posterieures. 

6. Methode selon les revendications 1 a 5, caracterisee en ce que les cles 
publiques de la liste sont utilisees sequentiellement dans un ordre predetermine lors 
de chaque mise a jour. 



7. Methode selon les revendications 1 a 6, caracterisee en ce que la liste des 
cles publiques est stockee dans une memoire non volatile, une cle utilisee pour une 
mise a jour est effacee definitivement de la memoire autorisant I'acces a la cle 
suivante pour la prochaine mise a jour. 

8. Methode selon les revendications 1 a 7 caracterisee en ce que, pour la mise a 
jour du logiciel d'un appareil d'une version N a une version R, avec une difference R- 
N entre la nouvelle version et la precedente excedant I'unite, au moins un message 
Mn encrypte avec une cle privee PKn est ajoute permettant de changer la cle 
courante Kn a la cle suivante Kn+1 dans la liste, la decryption reussie dudit message 
provoquant la deactivation de la cle courante Kn et la selection de la cle suivante 
Kn+1. 

9. Methode selon la revendication 8, caracterisee en ce que le nombre de 
messages M correspond au nombre de mise a jour separant la version initiale de 
Tappareil et la version finale de la mise a jour. 

10. Methode selon les revendications 1 et 2, caracterisee en ce qu'une installation 
d'une mise a jour est suivie par une incrementation d'un compteur ou un 
deplacement d'un pointeur indiquant le rang de la cle a selectionner dans la liste lors 
de la prochaine mise a jour, la liste des cles etant inchangee. 

1 1 . Methode selon les revendications 1 a 4, caracterisee en ce que le bloc de 
controle est encrypte successivement par les cles des mises a jour precedentes, 
chaque cle de la liste etant utilisee I'une apres I'autre pour decrypter la signature. 

12. Methode selon les revendications 1 a 10, caracterisee en ce que les appareils 
consistent en des decodeurs de television a peage, la mise a jour d'un decodeur 
etant effectuee par le telechargement, a partir d'un centre de gestion, d'un patch 
accompagne d'un bloc de controle, ledit bloc est stocke dans une memoire vive 
(RAM), et est decrypte avec une cle publique courante d'une liste contenue dans une 
premiere memoire non volatile du decodeur, puis verifie et en cas de concordance, 
une commande provoque Tinstallation du patch dans une seconde memoire non 
volatile et la desactivation de la cle courante. 



13. Methode selon la revendication 12, caracterisee en ce qu'une nouvelle liste de 
cles publiques est transmise au decodeur, ladite liste remplace la liste contenue 
dans la premiere memoire contenant des cles desactivees par des mises a jour 
reussies precedemment. 
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ABREGE 

La presente invention propose une methode de securisation de mise a jour de 
logiciels d'une pluralite de decodeurs basee sur la generation d'une signature au 
moyen d'une cle privee asymetrique. 

5 La mise a jour d'un decodeur etant effectuee par le telechargement, a partir d'un 
centre de gestion, d'un bloc de donnees comprenant un patch et sa signature, ledit 
bloc est stocke dans une memoire vive RAM. La signature est decryptee avec une 
cle publique courante d'une liste contenue dans une premiere memoire non volatile 
du decodeur, puis verifiee et en cas de concordance, une commande provoque 
10 Installation du patch dans une seconde memoire non volatile Flash et la 
deactivation de la cle courante. 

Le but de la presente invention est de reduire considerablement Timpact de la 
decouverte d'une cle privee par une analyse systematique du fonctionnement du 
logiciel du decodeur ou d'accroitre notablement le temps et les moyens necessaires 
15 au processus utilise pour sa determination. 
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